Decision Support Tools for Customer-Oriented Dispatching

Unavoidable disturbances induce the necessity of operations control and dispatching tasks in the timetable-driven rail traffic. Therefore, dispatching becomes one of the most relevant challenges for the economic success, since it directly affects the timeliness of passengers, which is a core indicator of customer satisfaction. Thus, the integration of passenger preferences into dispatching strategies is a reasonable extension of conventional dispatching algorithms. In this paper we discuss decision support tools to be used by dispatchers in order to achieve customer orientation. The tools are based on an agent-based simulation system modelling the complete German railway network with about 30000 trains and millions of passengers per day. We report tests of various dispatching strategies considering passenger information and aiming to reduce passenger waiting times. We show that even simple heuristics produce better results than the rule based dispatching strategies currently in use. 1 Ideas and Basics of Customer-Oriented Dispatching Unavoidable disturbances induce the necessity of operations control and dispatching tasks in timetable-driven rail traffic. Dispatchers of a railway have to make decisions about changes to the original train schedule often in a matter of minutes. Traditionally, railways often emphasise timeliness of trains and cost minimisation within the dispatching process. However, this tends to be suboptimal from the customer point of view. We argue that timeliness of customers is more important for the long-term economic success of a railway than timeliness of trains. With customer-oriented dispatching we mean dispatching strategies that give customer timeliness a higher priority than train timeliness. Obviously, we first have to determine measures how to judge customer timeliness, which certainly means different things to different people, thus being an extremely multi-faceted and complex aspect. Mainly, there are two different aspects of customer oriented dispatching: a) regarding wishes of passengers in the dispatching process through usage of passenger information, and b) proactive and individualised information of passengers using modern communication networks and mobile technology like cell F. Geraets et al. (Eds.): Railway Optimization 2004, LNCS 4359, pp. 171–183, 2007. c © Springer-Verlag Berlin Heidelberg 2007 172 C. Biederbick and L. Suhl phones, personalised digital assistants (PDA) or so called “smartphones” which are widely spread within industrialised countries. Both aspects can be implemented and established independently, but obviously they are closely related: The more information there is available, the better the quality of dispatching that can be achieved. In this paper, we focus on aspect a), because it seems to us that there is a lot of room to improve dispatching quality even with little information about passengers. Although customer orientation is getting more and more important in the competitive passenger traffic market, little is known about how to reliably measure customer satisfaction in railways and how to design dispatching strategies that maximise customer satisfaction. There are several established simulation tools available for railway traffic (cf. [12], as an example), however, they are usually technology-oriented aiming at optimal dispatching of trains and other equipment. In this paper, we show how simulating railway traffic in a complex network using intelligent software agents results in real-time decision support tools significantly enhancing the on-trip support for passengers thus reducing unscheduled waiting times during their trips. Furthermore, we show how the simulation system can be used to figure out good online-dispatching strategies in order to maximise customer satisfaction. With “dispatching strategy” we mean every algorithm capable of calculating dispatching decisions consisting of waiting instructions for single connecting trains waiting for late feeder trains in case of a connection conflict. In other words, a train – the feeder – is delayed by a disturbance and could not reach its scheduled connectors in time. If a connector does not wait for the corresponding feeder, all transit passengers of this specific connection will be delayed, if it waits, all passengers in the connector get into the risk of missing their connections. The implementation and test described in this paper were carried out with data from Deutsche Bahn AG. The complete German railway network with about 30000 trains and about five million passengers daily was implemented within our simulator. With this system, we were able to test various dispatching strategies considering passenger information and aiming in reduction of passenger waiting times. Topics related to railway dispatching and reliability have been discussed in literature during recent years (see [2, 5, 6, 7], for example), however, in this paper we take a more explicit view considering customer satisfaction as the main goal of disposition activities. The paper is outlined as follows: In the second section we describe our agentbased simulation test bed for simulating large railway networks, which leads to a simple architecture of co-operating decision support components for dispatchers. Section 3 describes the enhanced dispatching process and the components necessary for this; Section 4 presents some numerical results. In Section 5 the new information process is described, and in Section 6 we close with some conclusions drawn from extensive experimentation with this system. Decision Support Tools for Customer-Oriented Dispatching 173 2 Intelligent Software Agents for Simulation of Large Railway Networks A railway as a system consists of autonomous mobile actors, such as passengers, trains, and personnel. The system components act on a stable infrastructure, such as tracks, stations, and so on. A simulator of railway traffic needs to model all relevant groups of actors. A natural way to describe mobile autonomous components is to use intelligent software agents. Software agents are (broadly speaking) computer programs which are able to behave autonomously in a certain sense, interact with other software agents, thus building communities, and move within a digital network [12]. Because there are usually several interacting agents, we often speak about multi-agent systems. It is conceptually appropriate to use software agents to implement a microscopic view of the railway system, because an agent is usually configured to represent a microscopic item like one certain train or station, even one certain customer. From the computer science point of view, multi-agent technology can be understood as an advancement of object-oriented programming, thus presenting a new programming paradigm. Especially, the concepts of autonomous behaviour and intentionality provide new dimensions to model objects with control functionality; this is not possible with traditional object-oriented programming techniques. We generally distinguish between two basic variants of architecture models for multi-agent systems: deliberative and reactive architecture. Agents in the deliberative model behave analogously to expert systems as they are known in artificial intelligence. They possess an explicit symbolic model of their environment, together with logical inference mechanisms in order to be able to derive conclusions and evaluate possible actions. A well-known deliberative agent architecture model is the “Belief, Desire, Intention” model of [1]. Reactive agents react on certain stimuli from their environment with executing specified actions. The easiest ways of implementation are if-then rules, e.g., if obstacle ahead then go left. Agent goals are not given explicitly, intelligence arises incrementally a non-centralised way, leading to a new modelling paradigm for distributed systems. In our opinion, the agent concept is very well suited for modelling parallel and distributed simulation systems running on low-cost hardware. Furthermore, the agent concept enables us to integrate (autonomous) real world players, such as customers and dispatchers, trains and stations, and more specialised agents1, into the simulation, thus supporting customer information and distributed realtime dispatching as well. Using the agent paradigm, the simulation model was divided into several regions by simply building disjoint subsets of network vertices (e.g. stations) and arcs (tracks) as described in [4,8,11]. Every region contains one dedicated central dispatching agent, each of them assisted by several task agents, e.g., 1 The “special agents” will be discussed in forthcoming publications. 174 C. Biederbick and L. Suhl for carrying out more complex strategy calculations or to re-route passengers missing their connections (cf. Section 3). Then, the size of a (virtual) region is only limited by the dispatching productivity, i.e., the number of decisions computed per time unit. Of course, the regions should be chosen in such a way that communication costs are low within the cluster, and that there are enough communication resources available for peak demands (many delays in the network causing much dispatching activity). To ensure consistency, a central data storage for infrastructure data (especially the network topology) as well as timetable data (static and dynamic, i.e., with delays during simulation) were chosen. The system is based on the general system architecture introduced in [10]. Between regions, only border crossing trains and passengers are exchanged. Furthermore, dispatchers can receive expected delays and passenger data from trains in neighbouring regions by asking their “colleagues”. This becomes necessary when a connector waits for a feeder train still located in a neighbouring region. In our simulation model, every complex dispatching strategy is implemented as an agent as well, even when it has no typical agent properties (such as proactiveness or mobility), thus enabling us to use the load balancing mechanisms of the agent-based simulation environment. The dispatching process is modelled as follows: • Trains send disturbances occurring on their route to a central server. If a dispatcher has to decide, he will ask this server to receive the latest information. • A departing train asks the responsible dispatcher for permission. • The dispatcher computes a decision using different strategies (cf. Section 3) and assisting agents, e.g., the passenger router (cf. Section 4). He also determines whether the train has to wait for some other (technical or security) reason, e.g., congested tracks. • Resulting decisions will be sent to affected entities in the network, both trains and passengers. • Additionally, every train and station performs “passenger administration”. All passengers are continuously transferred from one administrative unit to the next one during the course of their trip. Of course, the dispatcher is the core component of this system. From an agent technology point of view he could be regarded as a deliberative information agent. This agent has to watch the state of the network and to act autonomously in case of present or predictable conflicts. Even if no feasible plan (with no missed connections) could be found, the dispatcher can use the passenger router to compute new routes for all affected passengers. The passenger agents then communicate with their real-world counterparts enabling on-trip-interaction with passengers. In other words, they are the distributed user-interface of the system, giving specific information to “their” passengers on the one hand, and collecting useful data from them to support dispatching decisions on the other. Decision Support Tools for Customer-Oriented Dispatching 175 3 Components of Customer-Oriented Dispatching for Enhancing the Dispatching Process Each dispatcher in the system is responsible for a disjunctive region of the railway network, calculating dispatching decisions for each train waiting for departure, based on the states of all entities within the system. At first, the dispatcher determines the set of actual and potential, i.e., probably forthcoming, conflicts in the controlled area. Then, the time window in which a solution has to be found is determined implying a set of possible decision strategies. The best strategy builds the recommendation for a human dispatcher if the system is used within real world. If it runs in simulation mode, the best calculated plan will be executed without intervention of a dispatcher. The internal architecture of the dispatching agent is outlined in Figure 1 It is based on the typical architecture of knowledge based systems. The dispatcher uses the passenger router in two ways: 1) Before a decision is made, alternative routes for affected passengers are determined. If all those passengers can be re-routed, no further delay is necessary. 2) After a decision, the router can be used by the agents representing passengers missing their connection to re-route their owners. Dispatching strategies are of crucial importance, because they have direct impact on customer satisfaction as measured by delays and missed connections. In order to rate passenger strategies we chose a simple measure which is directly influenced by dispatching decisions: We measured the individual and total passenger waiting time. Although there are many criteria defining customer satisfaction (cf. [9]), we think (passenger) timeliness to be the most important factor. To properly weight waiting times of customers we have to consider the circumstances under which the waiting takes place. Therefore, we define a parameter called waiting time quality: Does the customer wait in the train or at the station? If the latter, what type of station is it, i.e., is there any pastime, or is he or she forced to wait at the perhaps cold and windy platform? A second criterion influencing the quality of waiting time is the type of a trip. Waiting a few minutes longer may not be arduous if the customer is on a holiday trip, while it could be crucial for reaching a business appointment, while in both cases longer waiting times lead to disproportionate annoyances. Thus, passengers should not wait “too long” if dispatching can avoid it. This leads to waiting time costs for each passenger, which could be represented by utility functions (cf. [9]). Many other criteria are possible as well. In reality, the final decision has to be made by the (human) dispatcher: the role of the computer-based system is to provide optimal decision support. In general, we may categorise dispatching strategies according to the amount and quality of input information they require, as well as according to the art and amount of their running time which may be deterministic or stochastic. Usually, the amount or information required is closely related to the expected running 176 C. Biederbick and L. Suhl